Method and system for allocation of resources in an agile environment

ABSTRACT

A computer-implemented method is provided for optimizing allocation of resources across stories for a release within an Agile development environment. The method includes receiving (i) resource information representing a plurality of resources available for allocation to the stories, (ii) one or more story definitions, each story definition comprising a unique identifier and one or more story-level constraints corresponding to a story, (iii) release information, (iv) iteration information, and (iv) one or more optimization criteria. The method also includes generating a plurality of story-level allocation scenarios and determining one or more optimized story-level allocation scenarios from the plurality of story-level allocation scenarios. Each story-level allocation scenario satisfies the one or more story-level constraints associated with each story definition. Each optimized story-level allocation scenario optimizes assignment of iterations or allocation of resources to the stories to satisfy the one or more optimization criteria.

FIELD OF THE INVENTION

The invention relates generally to computer-implemented methods andapparatuses, including computer program products, for allocatingresources in an Agile environment, and more particularly, to generatingoptimized scenarios of resource allocation to Agile stories to satisfyone or more constraints associated with the stories as well ashigher-level optimization criteria.

BACKGROUND OF THE INVENTION

Product development management involves, in part, planning, organizing,securing and managing resources to bring about the successful completionof a project with respect to specific goals and objectives. Projectmanagers can manage resources using, for example, Agile developmentapproaches, which are characterized by factors such as relatively shorttime-frame intervals (often referred to as sprints or iterations),delivery of certain goals at the end of each iteration, and regularadaptation of requirements and designs in response to changingcircumstances. Exemplary changes in circumstances include changes inbusiness goals, changes driven by customer feedbacks, changes driven byimproved understanding of technological challenges, changes todownstream features based on cumulative knowledge, changes in skills andresources, and changes derived from improved knowledge of estimates ofwork completion based on team velocity.

Under Agile development methods, a project can be organized into one ormore features with each feature delivering a package of relatedfunctionalities that an end user generally expects to get all at once.In turn, each feature can be broken down into a collection of relatedstories with each story defining a particular functionality. Forexample, given a feature involving programming inline table resizing, itcan be broken down into three stories—resizing columns, resizing rowsand resizing the table itself. In addition, a working feature or productcan be produced at the end of a release, during which the feature orproduct is refined through successive iterations. Typically, eachiteration involves a team working through a full development cycleincluding the phases planning, designing and testing. Thus, Agilemethods minimize overall risks by allowing a project to adapt to changesquickly.

Even though the Agile model is generally preferred by developers, themodel still poses many challenges. One challenge for any team ofdevelopers is trying to accommodate changes in customer priorities anddemands throughout the life cycle of a project. Another challenge istrying to better estimate at a granular level how many and differenttypes of stories for any given feature or project the team can deliverover a release or even an iteration. In many cases, a team may not beable to deliver all the stories in a single iteration or a release dueto various subjective and objective constraints coming from stakeholders(e.g., project managers and/or customers). Furthermore, fluctuations inconstraints and resource availability make project planning even moredifficult.

SUMMARY OF THE INVENTION

Methods and apparatus are provided to optimize resource utilizationacross stories over a release period within the Agile developmentframework. The methods and apparatus overcome deficiencies in today'sAgile planning process and ensure that the time taken to plan a typicalrelease can be reduced from a week in existing processes to a matter ofhours or less. For example, time spent on planning can be reduced frombetween 5 and 7 days with existing processes to 3 or 4 of hours. In manycases, time spent on planning can be reduced by about 80% or more. Anoptimal fit of stories can be identified based on the constraintsprovided. A better feedback system can be implemented that uses actualeffort to estimate demand on a particular type of story. The presentinvention also generates better quality planning, enables faster andeasier updates to existing plans, and facilitates easier understandingof the impact of a scope trade off, which represents a balance betweenthe values of certain features or stories and the amount of effortsinvolved to deliver these features or stories.

A project management system can use constraint programming and/or linearprogramming to plan the allocation of resources to one or more storiesin a project for a release. The programming techniques can be based onthe techniques described in U.S. Pat. No. 7,991,632, the entire contentof which are incorporated herein by reference. Through the applicationof constraint programming, a project manager and/or a project team canrealize a high level of efficiency in a short time. Specifically, byapplying one or more supply-side and/or demand-side constraints, aproject developer can identity, for example, which stories need to bedelivered first or which story is instantly feasible without the needfor full re-planning. In some embodiments, linear programming can beemployed to realize similar goals.

In one aspect, there is a computer-implemented method, used in an Agileenvironment, for planning allocation of resources across a plurality ofstories in a project during a release. Within the Agile environment, therelease represents a deadline for delivering the stories and is dividedinto one or more iterations. Changes to the stories are incorporatedinto project planning at the beginning of each iteration and an enhancedplan for any remaining stories is delivered at the end of eachiteration. The method includes receiving, at a computing device, (i)resource information representing multiple resources available forallocation to the stories, (ii) one or more story definitions, eachstory definition comprising a unique identifier and one or morestory-level constraints corresponding to a story, (iii) releaseinformation defining the release, (iv) iteration information definingthe one or more iterations within the release, and (iv) one or moreoptimization criteria for a level different from a story level. Themethod also includes generating, using the computing device, multiplestory-level allocation scenarios. Generating each story-level allocationscenario includes assigning an iteration to each of the uniqueidentifiers and allocating one or more of the resources to one or moreof the unique identifiers. The assignment of the iterations and theallocation of the resources to the one or more unique identifierssatisfy the one or more story-level constraints associated with eachstory definition. The method also includes determining, using thecomputing device, one or more optimized story-level allocation scenariosfrom the story-level allocation scenarios. Such determination optimizesassignment of iterations or allocation of resources to the uniqueidentifiers to satisfy the one or more optimization criteria.

In another aspect, there is a computer program product, tangiblyembodied in a non-transitory machine-readable storage device, foroptimizing allocation of resources across stories in a project during arelease within an Agile development environment. The release representsa deadline for delivering the stories and is divided into one or moreiterations. Changes to the stories are incorporated into projectplanning at the beginning of each iteration and an enhanced plan for anyremaining stories is delivered at the end of each iteration. Thecomputer program product including instructions being operable to causedata processing apparatus to receive (i) resource informationrepresenting a plurality of resources available for allocation to thestories, (ii) one or more story definitions, each story definitioncomprising a unique identifier and one or more story-level constraintscorresponding to a story, (iii) release information defining therelease, (iv) iteration information defining the one or more iterationswithin the release, and (iv) one or more optimization criteria for alevel different from a story level. The computer program product alsoincludes instructions being operable to cause the data processingapparatus to generate a plurality of story-level allocation scenarios byassigning an iteration to each of the unique identifiers and allocatingone or more of the plurality of resources to one or more of the uniqueidentifiers. The assignment of the iterations and the allocation of theresources to the one or more unique identifiers satisfy the one or morestory-level constraints associated with each story definition. Thecomputer program product further includes instructions being operable tocause the data processing apparatus to determine one or more optimizedstory-level allocation scenarios from the plurality of story-levelallocation scenarios. Such determination optimizes assignment ofiterations or allocation of resources to the unique identifiers tosatisfy the one or more optimization criteria.

In other examples, any of the aspects above can include one or more ofthe following features. In some embodiments, determining one or moreoptimized story-level allocation scenarios includes selecting, using thecomputing device, a first story-level allocation scenario from theplurality of the story-level allocation scenarios and revising, usingthe computing device, assignment of iterations or allocation ofresources to the unique identifiers in the first story-level allocationscenario to satisfy the one or more optimization criteria. In someembodiments, determining one or more optimized story-level allocationscenarios includes assigning, using the computing device, a weight toeach of the one or more optimization criteria and determining, using thecomputing device, the one or more optimized story-level allocationscenarios by satisfying the one or more optimization criteria scaled bytheir respective weights. In some embodiments, determining one or moreoptimized story-level allocation scenarios includes determining, usingthe computing device, an order for applying the one or more optimizationcriteria and determining, using the computing device, the one or moreoptimized story-level allocation scenarios by satisfying the pluralityof optimization criteria successively applied in the order.

In some embodiments, the level different from the story level includesan iteration level, a release level, or a feature level. In someembodiments, the one or more story-level constraints includes one ormore start dates or date ranges, one or more end dates or date ranges,one or more resource constraints, a cost constraint, one or morelocation constraints, or any combination thereof. In some embodiments,the one or more optimization criteria include a resource utilizationcriterion, a schedule criterion, a risk level criterion, amaximum-number-of-features criterion, or any combination thereof.

In some embodiments, the plurality of resources includes one or morehuman resources, one or more physical resources, or any combinationthereof. In some embodiments, the plurality of resources includes one ormore physical resources including one or more computer resources, one ormore geographic locations, one or more supply materials, one or moreequipment items, or any combination thereof. In some embodiments, theresource information includes attribute information for one or more ofthe plurality of resources. The attribute information can include skillsinformation, geographic location information, language information,availability information, or any combination thereof, for one or morehuman resources.

In some embodiments, each story definition associated with the releasefurther includes information indicating a priority level. In such acase, allocating one or more of the plurality of resources to one ormore of the unique identifiers includes allocating resources to a firstunique identifier before allocating resources to a second uniqueidentifier. The first unique identifier is associated with a firstpriority level higher than a second priority level associated with thesecond unique identifier.

In some embodiments, assigning an iteration to each of the uniqueidentifiers includes assigning, using the computing device, a null valueto at least one unique identifier indicating that the story associatedwith the at least one unique identifier is canceled or not scheduled forthe release.

The method and computer program product can further includeautomatically executing the generating and the determining steps upondetecting a change to at least one of the resource information, thestory definitions, the release information, the iteration informationand the optimization criteria.

The method and computer program product can further include generatingan action plan based on the one or more optimized story-level allocationscenarios. The action plan includes at least one of modifying resourceallocation of the plurality of resources or acquiring additionalresources.

BRIEF DESCRIPTION OF THE DRAWINGS

The advantages of the technology described above, together with furtheradvantages, may be better understood by referring to the followingdescription taken in conjunction with the accompanying drawings. Thedrawings are not necessarily to scale, emphasis instead generally beingplaced upon illustrating the principles of the technology.

FIG. 1 is an exemplary flowchart depicting a general process flowassociated with the management of stories for a release plan.

FIG. 2 is an exemplary graphical user interface of a project managementsystem for receiving optimization criteria and allocation information.

FIG. 3 is an exemplary flowchart depicting a general process flowassociated with generating optimized allocation scenario(s) for storiesover one or more iterations of a release.

FIG. 4 is an exemplary flowchart depicting general process flowsassociated with reviewing story-level allocation scenarios and userselection of story-level allocation scenarios.

FIG. 5 is an exemplary flowchart depicting a general process flowassociated with approval of resource and/or story changes.

FIG. 6 a is an exemplary block diagram showing a design of a projectmanagement system.

FIG. 6 b shows exemplary architecture for deploying a project managementsystem.

FIGS. 7 a-d are exemplary graphical user interfaces depicting use caseexamples for utilizing a project management system to simulatestory-level allocation scenarios.

DESCRIPTION OF THE INVENTION

FIG. 1 is a flowchart 100 depicting a general process flow associatedwith the management of stories for a release plan. In particular, theflowchart 100 details the workflow through which a user can interfacewith a project management system to optimize the allocation of resourcesto stories in a release. The elements of the flow chart 100 aredescribed using the exemplary project management system 200 of FIG. 6 a.Optimization of resource allocation to stories can include receivingresource information, story definitions, iteration information andrelease information (step 102), receiving allocation information and oneor more optimization criteria (step 104), generating optimizedallocation scenario(s) for the stories over one or more iterations of arelease (step 106), reviewing the optimized story-level allocationscenario(s) (step 108), allowing an end user to select at least oneoptimized story-level allocation scenario (step 110) and generating anaction plan (step 112).

Resource information that is provided to and received (step 102) by theproject management system 200 can include information that representsresources available for allocation to one or more stories in a release.Story definitions that are provided to and received (step 102) by theproject management system 200 can represent the stories for whichallocation of the identified resources (including, e.g., the volume ornumber of resources) are required. Release information that is providedto and received (step 102) by the project management system 200 caninclude a deadline for delivering the stories as working feature(s) orproduct(s). Iteration information that is provided to and received (step102) by the project management system 200 can represent one or moreiteration deadlines within the release. In general, the resourceinformation, story definitions, iteration information and releaseinformation can be provided and/or received (step 102) as a datastructure such as, for example, textual lists, XML documents, classobjects (e.g., instances of C++ or Java classes), other data structures,or any combination thereof. Story definitions can be provided as a setof one or more baseline (e.g., currently planned and/or existing)stories, as a set of one or more new story definitions, or anycombination thereof.

Resource information can represent a plurality of resources, which canrange from human personnel (e.g., computer programmers, accountants,employees, consultants, etc.) to physical resources (e.g., a computerresources, infrastructure resources such as a geographic locations orbuildings/office space, any type of supply or manufacturing material,physical equipment items, etc.). Human resource information can includeattribute information defining one or more of any of the following: typeattributes (e.g., full-time employee, part-time employee, contractor,temp, etc.), role attributes (e.g., project manager, architect, analyst,QA engineer, database manager/administrator, computer programmer),role-level attributes (e.g., a principal role, a senior role, anentry-level role, a graduate role, etc.), skill attributes (e.g., Java,C++, or generally any knowledge/ability to undertake a requiredactivity), geographic attributes (e.g., one or more cities/countries orother locations where person is available to work), education attributes(e.g., Ph.D., M.B.A., J.D., etc.), language attributes (e.g., French,German, etc.), cost attributes (e.g., $/hour), experience attributes(e.g., years of experience working on regulatory compliance),fungibility, human fragmentation attributes (e.g., the capability to beassigned to multiple tasks), security attributes (e.g., securityclearance, etc.), criticality attributes (e.g., a measure of theimportance of a human resource), and/or any combination thereof.

Physical resource information can include attribute information definingone or more of any of the following: geographic attributes (e.g., one ormore locations where physical resource can be used or accessed), costattributes (e.g., cost to use per hour, cost of supply per unit, etc.),availability attributes (e.g., information indicating times/dates and/orlocations that the resource is available for use and not yet assigned),supply attributes (e.g., amount of supply), throughput attributes (e.g.,network bandwidth, system capacity, physical space, etc.), securityattributes, and/or any combination thereof. In some embodiments, theplurality of resources represented by the resource information caninclude both human personnel and physical resources in any combinationthereof.

Release information, which provides a deadline for delivering thestories as working feature(s) or product(s), can include a start-date,an end-date, a duration limitation, and/or any combination thereof.Iteration information provides one or more iteration deadlines within arelease. Similar to the release information, iteration information forone iteration can include a start-date, an end-date, a durationlimitation, and/or any combination thereof. Exemplary iterationinformation includes the earliest start date, latest finish date, or anestimate of how many days an iteration may take. Iterations in a singlerelease can have the same duration or varying durations. In someembodiments, if a release plan includes one iteration, the duration ofthe release and the duration of the iteration are the same. In someembodiments, if several iterations are defined for a release plan, theduration of each iteration is shorter than that of the release.

A story can be represented by at least a starting date and an end dateor a specific iteration during which the story is expected to becompleted. Completion of a story also requires certain amount ofresources. Specifically, a story can be defined by one or morestory-level constraints including, for example, one or more resourceconstraints, schedule constraints, cost constraints, risk constraints,criticality constraints, technology constraints, or any combinationthereof.

Resource constraints of a story define what resources are required orcan be used for the successful completion of the story. Exemplaryresource constraints include human or machine utilization level, teamutilization level, resource fragmentation level and locationfragmentation data (e.g., distributed agile teams.) In some embodiments,a resource constraint can define a minimum or maximum number ofresources required. Resource constraints can also specify a minimumlevel of experience, certification, and/or security clearance. Asidefrom resource constraints that specify a general constraint, resourceconstraints can also specify a specific resource (e.g., the name of aparticular person or physical resource). In some embodiments, resourceconstraints can include an estimate of effort required to complete astory. For example, if the probability of timely completing a task ishigh, such as around 90%, then less effort is required. In this case,the effort level can be expressed as “highly probable” (HP). Incontrast, if the probability of timely completing a task is lower, suchas around 50%, then more effort is required. In this case, the effortlevel can be expressed as “aggressive but possible” (ABP). In general,resource constraints can be tied to or associated with any resourceattribute described above.

Schedule constraints for a story can include a start-date, an end-date,one or more milestone date constraints, a duration constraint, aniteration constraint, or any combination thereof. Exemplary scheduleconstraints include earliest start date, latest finish date, or anestimate of how many days, expressed as points, a story may take. Insome embodiments, a schedule constraint for a story can be defined as ahard constraint or an unchangeable constraint (e.g., for high prioritystories, for stories in-flight, or for stories in which the investmenttherein has surpassed a threshold amount). In some embodiments, a dateconstraint can be made dependent on the completion of any date or eventassociated with another story in the same feature, in the same projector in a different project.

A cost constraint for a story can set a minimum or maximum limit on theamount of money (e.g., spent on resources) estimated to be spent on thestory. A return-on-investment (ROI) constraint can set a minimum limiton the profitability or ROI of a story.

Criticality constraints (e.g., a priority level) for stories can be usedby the project management system 200 as a guide to order stories fordetermining which stories get allocated resources first in an iterationor release. A criticality constraint can also be used to determinewhether a story can be deferred to a later iteration or not implementedaltogether if insufficient resources are available for its successfulcompletion.

Each story can be identified by a unique identifier (e.g., the storyname, a number code, or other identifier). Accordingly, in addition tostory-level constraints, a story definition can also include its uniqueidentifier to enable the project management system 200 to reference thestory.

Before, after, and/or concurrently with receiving the resource, story,iteration and release information (step 102), allocation information canbe received by the project management system 200 (step 104). Allocationinformation can indicate the baseline state (e.g., current state) ofresource allocation to stories in a release. For example, the baselinestate can include information representing the current allocation of oneor more resources and/or assignment of iterations to stories in arelease. The baseline state of resource allocation can be generated bythe project management system 200 or by another resource planningsystem. Optimization criteria can represent higher-level objectives tobe achieved when determining one or more optimized story-level resourceallocation scenarios. An end user is allowed to define theseoptimization objectives, such as maximization of resource utilization ina release and/or minimization of story schedule delays in a release. Ingeneral, allocation information and optimization criteria can beprovided and/or received (step 104) as a data structure such as, forexample, textual lists, XML documents, class objects (e.g., instances ofC++ or Java classes), other data structures, or any combination thereof.

FIG. 2 is an exemplary graphical user interface of the projectmanagement system 200 for receiving optimization criteria and allocationinformation. From the graphical user interface, a user can choose togenerate an optimized story-level allocation scenario by selecting an“optimize” option box 114 followed by activating the “create new” button128. The user can customize the objectives to be achieved throughoptimization by selecting one or more optimization criteria from a listof criteria 116-124. One exemplary optimization criterion is a “featuresvs criticality” criterion 116 that allows a user to instruct the system200 to schedule as many features or stories as possible across one ormore iterations in a release plan or as many critical features orstories as possible, or a balance of the two considerations. Anotherexemplary optimization criterion is a “resource vs cost” criterion 118that allows a user to instruct the system 200 to allocate resources tostories without considering cost or resource utilization or specify aspecific balance of the two considerations. Another exemplaryoptimization criterion is a “deferrable criticality” criterion 120 thatallows a user to instruct the system 200 to defer execution of storieswith criticality levels less than or equal to a certain user-selectedthreshold. Other exemplary optimization criteria include: an “individualutilization” criterion 122 for allowing a user to specify the percentageof resource utilization per iteration, and a “global utilization”criterion 124 for allowing a user to specify the percentage of resourceutilization per release. Selection of an optimization criterion caninvolve a user making a selection on a sliding scale associated witheach criterion. For example, with respect to the “deferrablecriticality” criterion 120, a user can select a criticality threshold ona scale of 1 to 5 such that stories with criticality levels below thisthreshold may be deferred. In some embodiments, a user can specifydifferent weighting factors for one or more of the optimizationcriteria.

The graphical user interface can also provide a user with the option 126to load a previously stored allocation scenario and use it as thebaseline scenario instead of creating a new allocation scenario. Incertain embodiments, a user can load a previously stored allocationscenario as well as create a new allocation scenario. If a user choosesto load a previously stored allocation scenario, the user can select oneor more previously-created scenarios from a list of stored scenarios(not shown). In various embodiments, a user can use the graphical userinterface to manually edit (e.g., add, remove, modify) the baselineallocation of resources and/or assignment of iterations to stories. Invarious embodiments, a user can select one or more options of thegraphical user interface using option button(s), check box(es), textbox(es), drop-down list(s), etc., or any combination thereof.

FIG. 3 is a flowchart 150 depicting a general process flow associatedwith generating optimized allocation scenario(s) (step 106) for storiesover one or more iterations of a release. Generating optimizedstory-level allocation scenario(s) (step 106) includes, in part,simulating a single story-level allocation scenario (step 152), and canfurther include determining whether to simulate another story-levelallocation scenario (step 154). Simulating a single story-levelallocation scenario can include assigning iteration(s) to one or morestory identifiers (step 156) and allocating resources to one or morestory identifiers (step 158). If multiple story-level allocationscenarios are generated, an end user can further generate one or moreoptimized allocation scenarios (step 160). FIG. 3 illustrates thatassignment of iterations(s) to story identifiers (step 156) occursbefore allocation of resource(s) to story identifiers (step 158), butother process flows can be used. For example, allocation of resource(s)to story identifiers (step 156) can occur before or concurrently withassignment of iteration(s) to story identifiers (step 158).

Assignment of iteration(s) to story identifiers (step 156) can besubject to any schedule-based constraints. For example, if a story has ahard start-by-date constraint of February 1, then the project managementsystem 200 does not assign the associated story identifier to aniteration that ends before February 1. In another example, if a storyhas a set of hard start and end dates, the project management system 200need to assign an iteration to the story such that the start and enddates of the story fall within the time limitations associated with theiteration, as provided by the iteration information. Similarly,allocation of resources to story identifier(s) can be subject to anystory-level constraints included in the story definition for thecorresponding story identifier.

In some embodiments, assigning iterations to story identifiers (step156) and/or allocating resources to story identifiers (step 158) canoccur in order from those stories with the highest criticalityconstraint (e.g., priority level) to those stories with the lowestcriticality constraint. In some embodiments, allocating resources orscheduling iterations for stories can occur relative to each story'scost, risk, ROI, other story characterization, or any combinationthereof. For example, if two or more stories are equal with respect tothe ordering parameter, then the stories can be allocated based on theorder of their unique identifiers. In some embodiments, if by the timethe project management system 200 comes to allocate resources to a storywith an associated low criticality level and it is determined that allof the constraint-compatible resources available during the story's dateconstraint have already been assigned to more critical stories, then theless critical story may be assigned to an iteration later than the onethat satisfies the date constraint. The assignment of an iteration to aunique identifier can include assigning an iteration identifier, startand end dates, or a null value to indicate that the corresponding storyis canceled or not scheduled for the release.

In general, assignment of iterations (step 156) and/or allocation ofresources (step 158) can be accomplished using constraint programmingand/or constraint logic programming. Constraint programming searches fora state of a system (e.g., a project scenario) in which a large numberof constraints are satisfied at the same time. Constraint programmingtypically states the problem as a state of the system containing anumber of unknown variables. The constraint program then can search forvalues for all of the variables. In some embodiments, constraintprogramming can include temporal concurrent constraint programming(TCC), non-deterministic temporal concurrent constraint programming(NTCC), or both TCC and NTCC. Some exemplary examples of constraintlogic languages are: B-Prolog, CHIP V5, Ciao Prolog, ECLiPSe, SICStusProlog, GNU Prolog, Oz programming language, YAP Prolog, SWI Prolog,Claire programming language, Curry programming language, and Turtleprogramming language. The constraints used in constraint programming canbe one or more specified domains (e.g., Boolean domains, integerdomains, rational domains, linear domains, finite domains, or any mixedcombination thereof).

In some embodiments, hundreds of different story-level allocationscenarios associated with a release can be simulated. For example, theproject management system 200 can simulate every permutation ofiteration assignment and resource allocation that are possible subjectto the story-level constraints. In some embodiments, only apre-determined number of story-level allocation scenarios need to besimulated. Determining whether to simulate another story-levelallocation scenario (step 154) can be based on, for example, whether apredetermined number of story-level allocation scenarios is reached.

In some embodiments, the project management system 200 generates one ormore optimized story-level allocation scenarios (step 160) from themultiple story-level allocation scenario(s) (from step 154) to satisfycertain optimization criteria. Optimization criteria representhigher-level objectives to be achieved when determining the optimizedstory-level allocation scenarios. Specifically, after one or morestory-level allocation scenarios that satisfy the story-levelconstraints are simulated, at least one optimized story-level allocationscenario can be determined from the simulated scenarios by optimizing anobjective function while satisfying one or more higher-levelconstraints. The objective function and the higher-level constraints arethus defined to realize the objectives of the optimization criteria thatgovern the allocation of resources and/or assignment of iterations tostories in a release.

In general, an objective function determines how close a solution is tosatisfy one or more optimization criteria, and constraints associatedwith the objective function define the domain within which the solutionresides. When solving an optimization problem, the objective function isoptimized (i.e., maximized or minimized) while subject to theconstraints. Therefore, by appropriately defining the objective functionand the constraints, optimized solutions can be found that satisfy theobjectives of the optimization criteria. In some embodiments, constraintprogramming and/or constraint logic programming is used to solve theoptimization problems.

During optimization (step 160), at least one optimized story-levelallocation scenario is determined from the multiple story-levelallocation scenarios (from step 154) by optimizing one or more objectivefunctions while satisfying one more higher-level constraints. Theobjective functions and/or the higher-level constraints can be definedto realize one or more optimization criteria. An exemplary optimizationcriterion includes a utilization criterion, which can produce allocationscenario(s) to maximize resource utilization in one iteration, severaliterations or the entire release. Another exemplary optimizationcriterion includes a schedule criterion, which can produce allocationsscenario(s) with the least amount of time to complete withoutovershooting available resources. Another exemplary optimizationcriterion includes a risk level criterion, which can produce allocationscenario(s) with the least amount of cumulative risk associated with oneiteration, several iterations or the entire release. Another exemplaryoptimization criterion includes a feature criticality criterion, whichcan produce allocation scenario(s) that execute most critical storiessoonest in a release. Other exemplary optimization criteria include areturn-on-investment (ROI) criterion, which can produce allocationscenario(s) with the most expected gain minus cost over one iteration,several iterations or the entire release, a maximum-number-of-storiescriterion, which can produce allocation scenario(s) with the maximumnumber of stories for one iteration, several iterations or the entirerelease. In some embodiments, optimization is performed at thefeature-level, across one or more features of the stories in a release.For example, a risk level criterion can allocate resources to storiessuch that features of stories take the least amount of cumulative riskto complete in one iteration, several iterations or a release. Asanother example, allocation scenario(s) can be produced that executepartially completed features first in a release prior to those featuresthat have yet to start.

In some embodiments, an optimization criterion is a skill criterion asshown Table 1, in which case the objectives function and thehigher-level constraints are defined to optimally match skills for openpositions to available supplies. In some embodiments, an optimizationcriterion is a business-outcome criterion for stories, as shown in TableII.

TABLE I Match Skills Sub Features Additional Detail Specify how closeskills match should be, e.g., +/−1 level Define multiple Maximum numberof assignments allowed. assignments for individuals who have more thanone skill which is a fit for an open position Incorporate acceptableMaximum number of assignments allowed. degree of fragmentation This canalso be dependant on resource for a resource into type e.g. 1-2 forDev/QA; 5-7 for assignment decision Architects/DBA's Incorporatecritical Assumes some resources are not fungible, named resource fore.g., subject matter experts critical to stories into optimizationsuccess of project so their availability drives options for storyscheduling

TABLE II Business Outcome Sub Features Additional Detail Optimize forresource Ensure that stories are scheduled in such a utilization way asto use all available resources in the backlog within agreed tolerancese.g. +/−5% Optimize for story Schedule stories to minimize time tocomplete completion velocity without overshooting available resources inthe backlog Optimize for risk Acceptable cumulative risk score for agiven time period Optimize for criticality Prioritize highestcriticality stories first in a schedule and assign resources from thebacklog to satisfy the highest criticality stories Optimize for revisedSchedule stories to satisfy changing estimates estimate of resourceavailability in the backlog. These changes can be made on a periodicbasis throughout the life of a project. The changes in resourceestimates also reflect changes in the cost of the project.

An exemplary objective function used to allocate resources to stories ina release to maximize resource utilization (or minimize resource waste)is provided below:

$\begin{matrix}{{\min ( {\sum\limits_{k = 1}^{n}{P\lbrack {I_{k,}x} \rbrack}} )},} & ( {{Equation}\mspace{14mu} 1} )\end{matrix}$

where n represents the number of iterations in the release, I_(k)represents the k^(th) iteration in the release, and x represents aminimum resource utilization level that can be specified by a user usingthe sliding scale 122 or 124 of FIG. 2, for example. In addition,function P assigns a penalty to a specific iteration I_(k) if resourceutilization by stories during that iteration is below the minimum levelx.

An exemplary objective function used to allocate resources to stories tomaximize the number of features completed during one iteration, severaliterations or an entire release is provided below:

$\begin{matrix}{{\max ( {\sum\limits_{k = 1}^{n}{{F\lbrack S_{k} \rbrack}{S\lbrack S_{k} \rbrack}}} )},} & ( {{Equation}\mspace{14mu} 2} )\end{matrix}$

where n represents the number of stories in one iteration, severaliterations or a release and S_(k) represents the k^(th) story in theiteration(s) or release. In addition, function F represents afeature-points function, which computes the number of points requiredfor developing a feature containing one or more inter-dependent stories,and function S represents a successful and on-time complete function,which can be a binary function that is set to 1 when the k^(th) story iscompleted on time as planned or 0 when the k^(th) story is delayed.

An exemplary objective function used to allocate resources to stories tosatisfy schedule constraints in a release is provided below:

$\begin{matrix}{{\min ( {\sum\limits_{k = 1}^{n}{{P\lbrack S_{k} \rbrack}{S\lbrack S_{k} \rbrack}}} )},} & ( {{Equation}\mspace{14mu} 3} )\end{matrix}$

where n represents the number of stories in the release and S_(k)represents the k^(th) story in the release. Penalty function P assigns apenalty to a specific story S_(k) if the story is not implemented asplanned based on a request by customers, for example. Function Srepresents a successful and on-time complete function.

In addition, optimization criteria can be defined to determine themaximum number of stories that are feasible to implement in one or moreiterations of a release based on existing supply of resources availableto meet the demand associated with each story. Therefore, in someembodiments, resources available for allocation may not be sufficient tosatisfy all story resource demands. In such a situation, the allocationsystem can defer some stories by not including them in a preferred orplanned iteration. Instead, a deferred story can be included in asubsequent iteration. In some cases, a deferred story may not bescheduled at all for the release in view of resource availability. Storydeferral can be based on the criticality and/or priority of the stories(e.g., stories that are least critical are most likely to be deferred orcancelled).

In some embodiments, if an end user changes any one of the constraintsfor the stories and/or resource availability associated with a release,the project management system 200 can automatically re-run thesimulation (step 106) to determine one or more new allocation scenariosfor the release that satisfy the changed constraints. In general, theproject management system 200 provides a dynamic planning process to auser, allowing the user to add new stories at any point of a project andadjust the scope of an iteration or release. For instance, the projectmanagement system 200 can reduce or increase the number of iterations ina release any time during the execution of the release based on theoptimization results. The project management system can also reduce orincrease the number of stories per iteration in a release at any pointduring the execution of the release.

In some embodiments, a plurality of optimization criteria can be used.Each criterion can be scaled by a weight assigned to the criterion. Forexample, optimization can be performed to maximize resource utilizationand satisfy schedule constraints based on the objective functionsprovided in Equations 1 and 3. In addition, because different sets ofoptimized allocation scenario(s) can be generated depending on the orderin which optimization criteria are applied, an end user can specify aspecific order for applying the optimization criteria.

In some embodiments, determining optimized story-level allocationscenarios includes selecting and revising one or more of the simulatedstory-level allocation scenarios (from step 154) to optimize anobjective function and satisfy one or more higher-level constraints.Therefore, an optimized story-level allocation scenario may be differentfrom any one of the simulated story-level allocation scenarios thatsatisfy the story-level constraints. In some embodiments, assignment ofiterations to stories in an optimized allocation scenario is changed incomparison to the assignments in the simulated allocation scenarios. Insome embodiments, allocation of resources in an optimized allocationscenario is changed in comparison to the allocations presented in thesimulated allocation scenarios. In some embodiments, multiple optimizedallocation scenarios are generated and ranked according to how well theyoptimize the objective function while satisfying the higher-levelconstraints. In addition, the project management system 200 can generateoptimized allocation scenario(s) (step 106) for multiple releasesconcurrently.

This hierarchical approach to story planning, as illustrated in FIG. 3,is advantage because optimization is performed at both the story level(i.e., simulating project portfolio allocation scenarios that satisfythe story-level constraints) and higher level (i.e., generatingoptimized project portfolio allocation scenarios that satisfy theoptimization criteria associated with one or more iterations in arelease, the entire release or at a feature level). Consequently, theproject management system 200 advantageously provides the user with anoptimum set of scenarios to review.

FIG. 4 is a flowchart 162 depicting general process flows associatedwith reviewing story-level allocation scenario(s) (step 108) and userselection of story-level allocation scenario(s) (step 110) according tosome embodiments. Reviewing story-level allocation scenario(s) (step108) can include determining whether there are any existing allocationscenarios (e.g., either a baseline scenario or previously simulatedscenarios) (step 164), reviewing a single story-level allocationscenario if there are no existing scenarios (step 166) orreviewing/comparing two or more story-level allocation scenarios ifthere are previously saved scenarios (step 168). Advantageously,comparing story-level allocation scenarios generated at two differentpoints in time allows a manager to determine what is different betweenthe scenarios and/or to help formulate feedback in possibly trying a newsimulation with different optimization parameters and resourceallocations.

User selection of at least one story-level allocation scenario (step110) can include determining whether to implement a particularstory-level allocation scenario for the current Agile iteration (step170). If the scenario is selected for implementation, then the scenariois saved for implementation (step 172) and an action plan cansubsequently be generated (step 112). If a user chooses not to implementa story-level allocation scenario for the current Agile iteration, thenthe user determines (step 174) whether to delete the story-levelallocation scenario (step 176) or save the story-level allocationscenario for comparison and/or implementation at a later iteration (step178). The user can determine whether to end the session (step 180) or toreiterate the process (step 182) by trying to generate additionalscenario simulations with existing parameters (step 106) or modify theinput parameters to generate different simulations (step 102).

Generating an action plan for a selected story-level allocation scenario(step 112) can include generating instructions to resource managersand/or project managers to affect an actual change of resourceallocation(s) and/or iteration assignment of iteration to stories. Anaction plan can also include a set of data highlighting changesnecessary to move from the current state of allocation of resources tostories to the desired story-level allocation scenario. For example, anaction plan can include acquisition of addition resources to meet ananticipated need, such as hiring more human personnel and/or purchasingmore physical resource. An action plan can also provide provisions fortraining existing human personnel or upgrading existing physicalresources.

In some embodiments, the project management system 200 can provide alist of the gaps in resources to a user, highlighting those resourcedemands by stories that cannot be satisfied due to resourceunavailability. Based on the list, the project management system 200 cangenerate one or more action plans to remedy the resource gaps, such asplans to perform additional hiring, outsourcing, or training. Theseplans can be implemented during the current or subsequent Agileiterations, after which resource availability in the project managementsystem can be updated accordingly.

FIG. 5 is a flowchart 185 depicting a general process flow associatedwith approval of resource and/or story changes that result from theselection of an optimized story-level allocation scenario (step 110)according to some embodiments. In particular, flowchart 185 details aprocess (e.g., a handshake process) for implementing a simulatedstory-level allocation scenario. An action plan is first generated (step112), which can include generating a set of data indicating the one ormore changes necessary to move from the baseline state of the project tothe desired project represented by the story-level allocation scenariothat was selected for implementation. Implementation of a project caninclude flagging changes in resource allocations and/or story schedulingas “pending” (step 186), sending flagged changes to project managers andproject participants for review (step 187), determining whether anychange has been approved (step 189), updating the status of approvedchange(s) to be “approved” (step 190) and of unapproved change(s) to be“rejected” (step 191), emailing notifications of status updates (step192), and/or updating the status of the story-level allocation scenario(step 193). In some embodiments, sending flagged changes to projectmanagers and project participants for review (step 187) can beimplemented using the handshake/organization data API 240 in order tointerface with existing resource/project management systems 270 and/orHR management systems 280, as shown in FIG. 6A.

FIG. 6A is a block diagram showing a design of a project managementsystem 200 according to some embodiments. The project management system200 includes a combination of processes and software modules. Theworkflow of the Agile optimization processes 205 can be described usingthe exemplary flowcharts 100, 150, 162 and 185 of FIGS. 1 and 3-5,respectively. Software modules can include a graphical user interface(GUI) module 210, a user functions module 220, a scenario and user datastorage module 230, a handshake/organization data application interface(API) module 240, an optimization engine API module 250, and/or anoptimization engine module 260. In some embodiments, the projectmanagement system 200 can also be implemented as a Software as a Service(SaaS) (e.g., deployed to run over the Internet and/or a private localor wide area network).

GUI module 210 can handle user access (e.g., login and/or logout), useradministration (e.g., any of the administration functions associatedwith the support and/or management of the system 200), widget management(e.g., providing the end user with the capability to arrange and savepreferences for display of data within the browser area), and/or otherGUI services.

User function module 220 can provide functions to users in their use ofthe project management system 200. For example, user function module 220can include a story-level allocation scenario comparison engine (e.g.,to allow the user to compare different scenarios (step 168)), anorganization browser, a schedule manager module (e.g., to allow the userto modify in any way the assignment of a story to an iteration), anoptimization parameter control module (e.g., during step 106 to providethe user with an interface to modify the objective function for theapproach illustrated in FIG. 3, thus providing flexibility foroptimizing resource allocation and scheduling associated with one ormore stories), a resource management module (e.g., during steps 102 or104 to allow the user access to view/define resource information, suchas skills/roles/locations/costs, and/or to manually assign resources toone or more stories), a deferred stories module (e.g., to manage and/oralert the user about stories that have been deferred), an import/exportmodule (e.g., to load previously saved scenarios or to save scenarios toa storage device), and/or other modules that specify user functions.

In some embodiments, the schedule manager can allow the user directinteraction with multiple story schedules and resource allocations. Theschedule manager can also display outcome(s) and/or change(s) associatedwith an optimization calculation, highlight stories based on selectedcriteria (e.g. low/medium/high risk), allow a user to view storyresource information in greater detail, and/or highlight dependenciesthat impact rescheduling. The scenario comparison engine can allowcomparison(s) of key information across each scenario to inform theuser's decision making. The organization browser can allow the user toselect a level in organization for optimization activity, can integratewith an HR system for organization detailed information, and/or cancross references organization data with story and/or resource data toform appropriate views. The optimization parameter control module canallow the user to select optimization parameter(s) for each scenario,view parameter(s) selected by currently active scenarios, and/orset/view color coding associated with variations in parameter levels.The resource management module can provide collated view(s) of allstories, drill down capability by categorization, dynamical updatesbased on optimization changes, and/or resource thresholds that can beset graphically to highlight over/under runs versus leveled plans. Thedeferred stories module can provide a memory storage management forcancelled stories (either manually or via optimization). Theimport/export module can provide capability for import and export of avariety of information form the system (e.g., scenario information,comparison data, parameters, and/or deferred story data).

Scenario and user storage module 230 can provide processing functionsfor a data model that can be used as part of the creation, optimizationand/or management of story-level allocation scenarios. For example, as apart of the initial input of resource, story and iteration information(step 102) and/or optimization criteria and allocation information (step104) from a project management system, module 230 can store a baselineset of data within a base schema. The base schema can reflect both theworking data model as well as an interface API schema mapping. Scenarioand user storage module 230 can also provide functionality to save/loadstory allocation scenarios. Workflow status (e.g., draft, submitted,in-planning, executed, complete, etc.) can also be stored in a datamodel.

Organization data API module 240 can provide integration with workflowsfrom other resource/project management systems 270 and/or HR managementsystems 280. In some embodiments, the design for an interface with otherresource and project management systems can use the following type ofmodel APIs through web services. Each web service can include a baseclass with several to many methods plus related data set classes. Thesystem can include three general kinds of APIs: generic APIs (e.g., APIsthat explore other resource/project management systems 270),project-specific APIs that are specific to performance and targetProject Web Access features, and project-specific APIs that areavailable through the Shared Service Provider URL, but only have publicmethods documented.

Optimization engine API module 250 can provide a two way API with stateawareness held either at the side of optimization engine module 260 orat the side of the workflow engine 205. Optimization engine API module250 can forward any information regarding a story-level scenario (e.g.,resource information, story definitions, current allocations, etc.), andany input information established (step 104) by the user. Initially, abaseline story-level allocation scenario data set can be sent tooptimization engine 260 with initial constraints parameters. Afteroptimization engine 260 has performed a simulation, it can providefeedback to the workflow 205 including updated information on thesimulated story-level allocation scenario.

Optimization engine module 260 can perform two functions: generateoptimized story-level allocation scenario(s) (step 108) and/or provideoutput detailing any change (step 112) associated with an inputstory-level allocation scenario after processing.

FIG. 6B is an exemplary system architecture 300 for deploying theproject management system 200. The architecture includes database(s)310, business services module(s) 320, middleware module(s) 330,client-side module(s) 340 and browser user interface(s) (UIs) 350.

The database(s) 310 can include one or more oracle databases 302 forstoring story definitions, resource information, iteration informationand release information from one or more data sources 304 (step 102). Inaddition, the oracle databases 302 can store allocation information,such as prior baseline story-level allocations, and optimizationcriteria (step 104).

The business services module(s) 320 perform optimization relatedfunctions. The business services modules 320 can include a resourcemodule 312 for modeling resource availability and/or demand using, forexample, the Hibernate program, which can map resource information inthe databases 302 to Java classes and provide data query and retrievalfunctions. The resource models generated by the resource module 312 areprovided to the services module 314, which transforms the businessresource models from the resource module 312 to optimization domainmodels that can be consumed by the optimization module 316. The servicesmodule 314 can also provide reverse transformation from optimizationdomain models to business resource models. Based on the optimizationdomain models generated by the services module 314, the optimizationmodule 316 allocates resources to stories by performing constraint-basedprogramming. In an exemplary implementation, constraint programming isimplemented using CHOCO, a java-based library designed to solveconstraint-based problems.

The middleware module(s) 330 connect back-end components (e.g. thedatabase(s) 310 and the business services module(s) 320) to client-sideapplications 340. The middleware module(s) 330 can include a remotingand web-messaging module 322, such as BlazeDS, for allowing a user toconnect to back-end distributed data and push data to applications. Themiddleware module(s) 330 can also include a model-view-controller (MVC)module 324 for isolating domain logic (e.g., application logic for theuser) from user interface (e.g., input and presentation), thuspermitting independent development, testing and maintenance of each. Thetwo modules 322 and 324 are connected to a security module 326,implemented in the Spring framework, for example, to provideauthentication function and control user access to the back-end data.

The client-side module(s) 340 include one or more web applications,executable in a browser, for accessing back-end programs through themiddleware modules 330.

The browser UIs 350 can include a resource UI 342 for allowing an enduser to access the web applications implemented by the client-sidemodule(s) 340, thus permitting user interaction with the back-endprograms. The resource UI 342 can be implemented in Adobe Flex, AdobeFlash Player, or other types of multimedia software. The browser UIs 350can also include a resource optimization UI 344, implemented inJavaScript, jQuery or Java Server Faces, for example. The resourceoptimization UI 344 can provide a user with a different (oftenoptimized) user experience in comparison the resource UI 342. In someembodiments, the resource optimization UI 344 provides user access tothe same back-end functionalities as the resource UI 342, but withdifferent technology. In some embodiments, one or both of the resourceUI 342 and the resource optimization UI 344 are connected to thesecurity module 326 for authenticating the end user prior to allowingthe end user to access resources through the UIs.

USE CASE EXAMPLES

FIGS. 7 a-d are graphical user interfaces depicting use case examplesfor utilizing a project management system to simulate story-levelallocation scenarios. FIGS. 7 a-d are not necessarily drawn to scale;emphasis is instead generally being placed upon illustrating theprinciples of the invention. The project management system illustratedby the graphical user interfaces of FIGS. 7 a-d can be a part of theexemplary project management system 200 of FIG. 6 a, which can, in turn,use the process flows illustrated in FIGS. 1 and 3-5.

FIG. 7 a shows a graphical user interface 400 a illustrating anexemplary story allocation scenario, which includes a backlog area 402,a display area 404, and a resource information area 406. The backlogarea 402 provides a list of one or more stories yet to be scheduled as apart of a release. The project management system 200 is adapted toschedule as many stories in the backlog area 402 as possible subject tothe constraints defined for the stories as well as higher-orderoptimization criteria selected from, for example, the user interface ofFIG. 2. A user can add more stories to the backlog area 402 byactivating the “add story” button 408. In addition, the stories in thebacklog area 402 can be sorted by a number of constraints associatedwith the stories such that a user, based on the sorting, can instructthe project management program 200 which stories to schedule first. Forexample, stories situated highest in the list are likely to be scheduledfirst.

Once a story is scheduled by the project management system 200, thestory appears in the display area 404, which shows assignment of storiesto one or more iterations of different releases under an “iteration”view 405 of the display. For example, the story “Deploy Code toProduction Environment” is assigned to Iteration 2 of Release 1. In someembodiments, an Agile category corresponding to an assigned story can beshown in the display area 404. For example, the story “Deploy Code toProduction Environment” is associated with the “attribute mapping”category. In addition, the resource information area 406 illustrates theamount of available resources remaining for each iteration.

FIG. 7 b shows a graphical user interface 400 b illustrating anotherexemplary story allocation scenario. A user can sort the stories in thebacklog area 402 by different story-level constraints provided in thepull-down menu 410, including a criticality constraint (e.g., thestories are ranked according to their criticality), a feature constraint(e.g., related stories in the same feature are grouped together on thelist), a name constraint (e.g., stories are listed alphabetically bytheir unique identifiers), a points constraint (e.g., stories are sortedby the estimated number of days, expressed as points, to complete), alow probability of completion constraint (e.g., stories with a lowprobability of completion (i.e., require more effort) are rankedhigher), a high probability of completion constraint (e.g., stories witha high probability of completion (i.e., require less effort) are rankedhigher), a ETC constraint (e.g., stories are sorted by their “estimatedeffort to completion” rating). In addition, the display area 404 canshow assignment of stories to iterations under the “iteration” view 405of the display, along with the number of points associated with eachassigned story. For example, the story “Deploy Code to ProductionEnvironment,” which is assigned to Iteration 2 of Release 1, takes 6points to complete. In addition, it has an ABP of 5, HP of 7 and ETC of1.

FIG. 7 c shows a graphical user interface 400 c illustrating anotherexemplary story allocation scenario. The display area 404, in additionto showing assignment of stories to iterations under the “iteration”view 405 and the number of points associated with each story, can alsoshow the roles of the human resources assigned to complete each story.For example, the project management system 200 allocates one person 412to complete the story “Deploy Code to Production Environment” duringIteration 2 of Release 1.

FIG. 7 d shows a graphical user interface 400 d illustrating anotherexemplary story allocation scenario. The display area 404 can showassignment of stories to releases under a “roadmap” view 414, whichillustrates a story-level allocation scenario for multiple releases inthe form of a timeline/roadmap. This format allows a user to review theoverall impact on a particular release or on multiple releases whenfunctionalities scheduled for delivery are changed. This timeline can bechanged with each Agile iteration as well as with each change inconstraints. In some embodiments, display of the timeline/roadmap 404can provide zoomed-in or zoom-out views.

In some embodiments, the project management system supports simultaneousscheduling and resource allocation for multiple projects. Specifically,the project management system can execute the general process flow ofFIG. 1 for multiple projects concurrently. In the exemplary graphicaluser interface 400 d of FIG. 7 d, allocation and scheduling status formultiple projects are shown under different “tracks,” such as undertracks 416 and 418. These tracks allow an end user to organize multiplestreams of work concurrently. In some embodiments, projects are dividedinto tracks by geography, domain and/or product division. In someembodiments, a different backlog is maintained for each track, whichincludes its own set of resources available for allocation to thecorresponding track. Alternatively, a common backlog can be maintainedfor all or a portion of the tracks.

The above-described techniques can be implemented in digital and/oranalog electronic circuitry, or in computer hardware, firmware,software, or in combinations of them. The implementation can be as acomputer program product, i.e., a computer program tangibly embodied ina machine-readable storage device, for execution by, or to control theoperation of, a data processing apparatus, e.g., a programmableprocessor, a computer, and/or multiple computers. A computer program canbe written in any form of computer or programming language, includingsource code, compiled code, interpreted code and/or machine code, andthe computer program can be deployed in any form, including as astand-alone program or as a subroutine, element, or other unit suitablefor use in a computing environment. A computer program can be deployedto be executed on one computer or on multiple computers at one or moresites.

Method steps can be performed by one or more processors executing acomputer program to perform functions of the invention by operating oninput data and/or generating output data. Method steps can also beperformed by, and an apparatus can be implemented as, special purposelogic circuitry, e.g., a FPGA (field programmable gate array), a FPAA(field-programmable analog array), a CPLD (complex programmable logicdevice), a PSoC (Programmable System-on-Chip), ASIP(application-specific instruction-set processor), or an ASIC(application-specific integrated circuit), or the like. Subroutines canrefer to portions of the stored computer program and/or the processor,and/or the special circuitry that implement one or more functions.

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital or analog computer.Generally, a processor receives instructions and data from a read-onlymemory or a random access memory or both. The essential elements of acomputer are a processor for executing instructions and one or morememory devices for storing instructions and/or data. Memory devices,such as a cache, can be used to temporarily store data. Memory devicescan also be used for long-term data storage. Generally, a computer alsoincludes, or is operatively coupled to receive data from or transferdata to, or both, one or more mass storage devices for storing data,e.g., magnetic, magneto-optical disks, or optical disks. A computer canalso be operatively coupled to a communications network in order toreceive instructions and/or data from the network and/or to transferinstructions and/or data to the network. Computer-readable storagemediums suitable for embodying computer program instructions and datainclude all forms of volatile and non-volatile memory, including by wayof example semiconductor memory devices, e.g., DRAM, SRAM, EPROM,EEPROM, and flash memory devices; magnetic disks, e.g., internal harddisks or removable disks; magneto-optical disks; and optical disks,e.g., CD, DVD, HD-DVD, and Blu-ray disks. The processor and the memorycan be supplemented by and/or incorporated in special purpose logiccircuitry.

To provide for interaction with a user, the above described techniquescan be implemented on a computer in communication with a display device,e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display)monitor, for displaying information to the user and a keyboard and apointing device, e.g., a mouse, a trackball, a touchpad, or a motionsensor, by which the user can provide input to the computer (e.g.,interact with a user interface element). Other kinds of devices can beused to provide for interaction with a user as well; for example,feedback provided to the user can be any form of sensory feedback, e.g.,visual feedback, auditory feedback, or tactile feedback; and input fromthe user can be received in any form, including acoustic, speech, and/ortactile input.

The above described techniques can be implemented in a distributedcomputing system that includes a back-end component. The back-endcomponent can, for example, be a data server, a middleware component,and/or an application server. The above described techniques can beimplemented in a distributed computing system that includes a front-endcomponent. The front-end component can, for example, be a clientcomputer having a graphical user interface, a Web browser through whicha user can interact with an example implementation, and/or othergraphical user interfaces for a transmitting device. The above describedtechniques can be implemented in a distributed computing system (e.g., acloud-computing system) that includes any combination of such back-end,middleware, or front-end components. The above described techniques canbe implemented as a Software-As-A-Service (SaaS) model or using amulti-tiered approach.

Communication networks can include one or more packet-based networksand/or one or more circuit-based networks in any configuration.Packet-based networks can include, for example, an Ethernet-basednetwork (e.g., traditional Ethernet as defined by the IEEE or CarrierEthernet as defined by the Metro Ethernet Forum (MEF)), an ATM-basednetwork, a carrier Internet Protocol (IP) network (LAN, WAN, or thelike), a private IP network, an IP private branch exchange (IPBX), awireless network (e.g., a Radio Access Network (RAN)), and/or otherpacket-based networks. Circuit-based networks can include, for example,the Public Switched Telephone Network (PSTN), a legacy private branchexchange (PBX), a wireless network (e.g., a RAN), and/or othercircuit-based networks. Carrier Ethernet can be used to providepoint-to-point connectivity (e.g., new circuits and TDM replacement),point-to-multipoint (e.g., IPTV and content delivery), and/ormultipoint-to-multipoint (e.g., Enterprise VPNs and Metro LANs). CarrierEthernet advantageously provides for a lower cost per megabit and moregranular bandwidth options.

Devices of the computing system can include, for example, a computer, acomputer with a browser device, a telephone, an IP phone, a mobiledevice (e.g., cellular phone, personal digital assistant (PDA) device,laptop computer, electronic mail device), and/or other communicationdevices. The browser device includes, for example, a computer (e.g.,desktop computer, laptop computer, mobile device) with a world wide webbrowser (e.g., Microsoft® Internet Explorer® available from MicrosoftCorporation, Mozilla® Firefox available from Mozilla Corporation).

One skilled in the art will realize the invention may be embodied inother specific forms without departing from the spirit or essentialcharacteristics thereof. The foregoing embodiments are therefore to beconsidered in all respects illustrative rather than limiting of theinvention described herein. Scope of the invention is thus indicated bythe appended claims, rather than by the foregoing description, and allchanges that come within the meaning and range of equivalency of theclaims are therefore intended to be embraced therein.

1. A computer-implemented method, used in an Agile environment, forallocating resources across a plurality of stories in a project during arelease and scheduling the stories across a plurality of iterationswithin the release, wherein 1) each story represents at least one taskexecutable by an appropriate resource and 2) the release represents adeadline for delivering the stories and is divided into one or moreiterations representative of a sequence of time periods within therelease, the method comprising: receiving, at a computing device, (i)resource information representing a plurality of resources available forallocation to the stories, (ii) one or more story-level constraintscorresponding to each story, and iii) one or more optimization criteriafor a level different from a story level; applying, using the computingdevice, a first-level optimization scheme to generate a plurality ofstory-level allocation scenarios, wherein applying the first-leveloptimization scheme comprises: assigning an iteration to each of thestories; allocating one or more of the plurality of resources to one ormore of the stories; and satisfying the one or more story-levelconstraints associated with each story; and applying, using thecomputing device, a second-level optimization scheme to determine one ormore optimized story-level allocation scenarios from the plurality ofstory-level allocation scenarios to optimize assignment of iterationsand allocation of resources to the stories while satisfying the one ormore optimization criteria.
 2. The computer-implemented method of claim1 wherein applying a second-level optimization scheme to determine oneor more optimized story-level allocation scenarios comprises: selecting,using the computing device, a first story-level allocation scenario fromthe plurality of the story-level allocation scenarios; and revising,using the computing device, assignment of iterations or allocation ofresources to at least one story in the first story-level allocationscenario to satisfy the one or more optimization criteria.
 3. Thecomputer-implemented method of claim 1 wherein the level different fromthe story level includes an iteration level, a release level, or afeature level.
 4. The computer-implemented method of claim 1 whereinapplying a second-level optimization scheme to determine one or moreoptimized story-level allocation scenarios comprises: assigning, usingthe computing device, a weight to each of the one or more optimizationcriteria; and determining, using the computing device, the one or moreoptimized story-level allocation scenarios by satisfying the one or moreoptimization criteria scaled by their respective weights.
 5. Thecomputer-implemented method of claim 1 wherein applying a second-leveloptimization scheme to determine one or more optimized story-levelallocation scenarios comprises: determining, using the computing device,an order for applying the one or more optimization criteria; anddetermining, using the computing device, the one or more optimizedstory-level allocation scenarios by satisfying the plurality ofoptimization criteria successively applied in the order.
 6. Thecomputer-implemented method of claim 1 further comprising automaticallyexecuting, by the computing device, the applying steps upon detecting achange to at least one of the resource information, the story-levelconstraints, information related to the release, information related toat least one of the iterations, or the optimization criteria.
 7. Thecomputer-implemented method of claim 1 wherein the one or morestory-level constraints comprise: one or more start dates or dateranges, one or more end dates or date ranges, one or more resourceconstraints, a cost constraint, one or more location constraints, or anycombination thereof.
 8. The computer-implemented method of claim 1wherein the one or more optimization criteria comprise a resourceutilization criterion, a schedule criterion, a risk level criterion, amaximum-number-of-features criterion, or any combination thereof.
 9. Thecomputer-implemented method of claim 1 further comprising generating anaction plan based on the one or more optimized story-level allocationscenarios, the action plan comprising at least one of modifying resourceallocation of the plurality of resources or acquiring additionalresources.
 10. The computer-implemented method of claim 1 wherein theplurality of resources comprise one or more human resources, one or morephysical resources, or any combination thereof.
 11. Thecomputer-implemented method of claim 1 wherein the plurality ofresources comprises one or more physical resources including one or morecomputer resources, one or more geographic locations, one or more supplymaterials, one or more equipment items, or any combination thereof. 12.The computer-implemented method of claim 1 wherein the resourceinformation comprises attribute information for one or more of theplurality of resources.
 13. The computer-implemented method of claim 12wherein the attribute information comprises skills information,geographic location information, language information, availabilityinformation, or any combination thereof, for one or more humanresources.
 14. The computer-implemented method of claim 1 wherein thestory-level constraints corresponding to each story further includeinformation indicating a priority level.
 15. The computer-implementedmethod of claim 14 wherein allocating one or more of the plurality ofresources to one or more of the stories comprises allocating resourcesto a first story before allocating resources to a second story, whereinthe first story is associated with a first priority level higher than asecond priority level associated with the second story.
 16. Thecomputer-implemented method of claim 1 wherein assigning an iteration toeach of the stories comprises assigning, using the computing device, anull value to at least one story indicating that the story is canceledor not scheduled for the release.
 17. A computer program product,tangibly embodied in a non-transitory machine-readable storage device,for of allocating resources across a plurality of stories in a projectduring a release within an Agile environment and scheduling the storiesacross a plurality of iterations within the release, wherein 1) eachstory represents at least one task executable by an appropriate resourceand 2) the release represents a deadline for delivering the stories andis divided into one or more iterations representative of a sequence oftime periods within the release, the computer program product includinginstructions being operable to cause data processing apparatus to:receive (i) resource information representing a plurality of resourcesavailable for allocation to the stories, (ii) one or more story-levelconstraints corresponding to each story, iii) one or more optimizationcriteria for a level different from a story level; apply a first-leveloptimization scheme to generate a plurality of story-level allocationscenarios, wherein apply the first-level optimization scheme comprises:assign an iteration to each of the stories; allocate one or more of theplurality of resources to one or more of the stories; and satisfy theone or more story-level constraints associated with each story; andapply a second-level optimization scheme to determine one or moreoptimized story-level allocation scenarios from the plurality ofstory-level allocation scenarios to optimize assignment of iterationsand allocation of resources to the stories while satisfying the one ormore optimization criteria.
 18. The computer program product of claim 17wherein apply a second-level optimization scheme to determine one ormore optimized story-level allocation scenarios comprises: assign aweight to each of the one or more optimization criteria; and determinethe one or more optimized story-level allocation scenarios by satisfyingthe one or more optimization criteria scaled by their respectiveweights.